Systems and methods of aggregating healthcare-related data from multiple data centers and corresponding applications

ABSTRACT

Described herein are systems and methods for receiving healthcare data from a plurality data sources that generate and store data in various data model regimes, many of which are not standardized or are variants of a standard. The stored data may then be used to provide a plurality of customized execution environments and graphical user interfaces (GUIs) to users, based on each user&#39;s electronic healthcare records, insurance records, and wearable device data.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent ApplicationSer. No. 62/416,106, filed on Nov. 1, 2016, which is hereby incorporatedby reference in its entirety.

TECHNICAL FIELD

This application relates generally to healthcare-related softwareapplications and enterprise data management.

BACKGROUND

Electronic healthcare records (EHR) are generated and stored accordingto various company-specific, product-specific, or standardized datamodels, such as HL7 and FHIR. But healthcare software applications mayuse variants of standard data models or customized data models that arenot openly available. Moreover, EHR health data is often fragmented, butstill growing more so by the day. Consequently, stakeholders (e.g.,patients, insurers, care providers, employers) do not have access tocomprehensive datasets that needed to control health outcomes, andconsumers historically have not had any access to their own health data.Additionally, as user devices and products moving into a digital agewhere consumers can access fitness, nutrition, diagnosis and havemedical encounters all online through a growing number of platforms andproviders, there is a growing need for data to be aggregated andstandardized across disparate data sources.

SUMMARY

Disclosed herein are systems and methods capable of addressing theabove-described shortcomings and may also provide any number ofadditional or alternative benefits and advantages. As described herein,embodiments of the present disclosure relate to systems, apparatuses,methods, and computer program products for receiving healthcare datafrom a plurality data sources that generate and store data in variousdata model regimes, many of which are not standardized or are variantsof a standard. The stored data may then be used to provide a pluralityof customized execution environments and graphical user interfaces(GUIs) to users, based on each user's electronic healthcare records,insurance records, and wearable device data.

Disclosed herein are systems, apparatuses, methods, and computer programproducts for healthcare related software applications and enterprisedata management by collecting healthcare data records and healthcareactivity for a user to provide the user with healthcare reports andinsights created by consolidating all healthcare records and activityinto a single healthcare record generated by a common data model andthen analyzing the single healthcare record. Such systems, apparatuses,and methods of the present disclosure maximize healthcare riskprevention by using risk driven algorithms that learns from evolvingcontinuous healthcare trends of the user, increases speed of thehealthcare risk detection by dynamically re-evaluating risk as newhealthcare information becomes available for the user, and providesscalable healthcare solution to the user to serve detected healthcareproblem.

Systems, apparatuses, and methods of the present disclosure execute acomputer processor or any other server of a healthcare data system thatperforms various processes to collect data from multiple healthcaredata-generating systems containing various data fields and data types,indicating healthcare related information of users, in order todetermine whether the healthcare information contain attributes matchingattributes of one or more scenarios. Using the healthcare information,the computer processor or any other server of the healthcare data systemgenerate healthcare profiles that are associated with users of thehealthcare data system and determine any data gaps in the healthcareprofiles, which the computer or any other server of the healthcare datasystem eliminates by collecting additional and necessary data beforeprocessing to data analysis of the healthcare profiles. Analystcomputers may query and fetch these updated and completed healthcareprofiles from a database, and then generate and present healthcarereports and insights on a dashboard of a user computing device. This canensure that the user is provided with accurate healthcare information onthe dashboard of the user computing device all the time to maximizehealthcare risk prevention.

In one embodiment, a computer-implemented method may include receiving,by a computer, a set of one or more healthcare data records containing auser identifier from one or more healthcare data-generating systemsconfigured to generate a corresponding healthcare data record, whereinthe one or more healthcare data-generating systems are configured togenerate the corresponding healthcare data record according to one ormore data models associated with one or more formats and one or moredata types. The computer-implemented method may further includestandardizing, by the computer, the set of one or more healthcare datarecords received from the one or more healthcare data-generating systemsaccording to a common data model comprising mappings specifyingtransformations from the one or more formats for all healthcare datarecords having all of the one or more data types to a single format andsingle data type. The computer-implemented method may further includestoring, by the computer, the standardized set of one or more healthcaredata records into a first database configured to store a plurality ofhealthcare data records associated with a plurality of user identifiers.The computer-implemented method may further include generating, by thecomputer, in a second database, a user healthcare profile of a userassociated with the user identifier, the user healthcare profilecomprising one or more data fields containing data from the standardizedset of one or more healthcare data records associated with the useridentifier in the first database, wherein the second database isconfigured to store a plurality of user healthcare profiles associatedwith a plurality of user identifiers. The computer-implemented methodmay further include determining, by the computer, one or more actionitems associated with the data in each of the one or more data fields inthe user healthcare profile, wherein each action item is programmed tobe performed within a predetermined period of time. Thecomputer-implemented method may further include determining, by thecomputer, whether a record of execution of the one or more action itemsis available from the one or more healthcare data-generating systemsafter the predetermined period of time elapses, wherein the computer isconfigured to trigger a monitoring window for a time period fromdetermination of the one or more action items until the predeterminedperiod of time elapses. The computer-implemented method may furtherinclude identifying, by the computer, one or more data gapscorresponding to missing data in the user healthcare profile based onexamination of data in the one or more data fields of the userhealthcare profile that determines a link between data records containedin each of the one or more data fields, wherein the examination furthercomprises determining by the computer whether there is no record ofexecution of the one or more action items within the predeterminedperiod of time. The computer-implemented method may further include uponthe computer identifying the one or more data gaps in the userhealthcare profile when there is no link between the data recordscontained in each of the one or more data fields and there is no recordof execution of the one or more action items within the predeterminedperiod of time: transmitting, by the computer, a web link to a securewebpage comprising a request to a user computing device operated by theuser, wherein the request comprises an instruction to populate missinginformation in the one or more data gaps in the user healthcare profileand execute the one or more action items; updating, by the computer, theuser healthcare profile in the second database upon receiving theinformation corresponding to the one or more data gaps from the usercomputing device; and displaying, by the computer, one or morehealthcare reports based on evaluation of the data in the one or moredata fields of the user healthcare profile on a graphical user interfaceof the user computing device.

In another embodiment, a system may include a first database configuredto store healthcare data records and a second database configured tostore user healthcare profiles. The system may further include acomputer. The computer may be configured to a set of one or morehealthcare data records containing a user identifier from one or morehealthcare data-generating systems configured to generate acorresponding healthcare data record, wherein the one or more healthcaredata-generating systems are configured to generate the correspondinghealthcare data record according to one or more data models associatedwith one or more formats and one or more data types. The computer may beconfigured to standardize the set of one or more healthcare data recordsreceived from the one or more healthcare data-generating systemsaccording to a common data model comprising mappings specifyingtransformations from the one or more formats for all healthcare datarecords having all of the one or more data types to a single format andsingle data type. The computer may be configured to store thestandardized set of one or more healthcare data records into a firstdatabase configured to store a plurality of healthcare data recordsassociated with a plurality of user identifiers. The computer may beconfigured to generate, in a second database, a user healthcare profileof a user associated with the user identifier, the user healthcareprofile comprising one or more data fields containing data from thestandardized set of one or more healthcare data records associated withthe user identifier in the first database, wherein the second databaseis configured to store a plurality of user healthcare profilesassociated with a plurality of user identifiers. The computer may beconfigured to determine one or more action items associated with thedata in each of the one or more data fields in the user healthcareprofile, wherein each action item is programmed to be performed within apredetermined period of time. The computer may be configured todetermine whether a record of execution of the one or more action itemsis available from the one or more healthcare data-generating systemsafter the predetermined period of time elapses, wherein the computer isconfigured to trigger a monitoring window for a time period fromdetermination of the one or more action items until the predeterminedperiod of time elapses. The computer may be configured to identify oneor more data gaps corresponding to missing data in the user healthcareprofile based on examination of data in the one or more data fields ofthe user healthcare profile that determines a link between data recordscontained in each of the one or more data fields, wherein theexamination further comprises determining by the computer whether thereis no record of execution of the one or more action items within thepredetermined period of time. The computer may be configured to, uponthe computer identifying the one or more data gaps in the userhealthcare profile when there is no link between the data recordscontained in each of the one or more data fields and there is no recordof execution of the one or more action items within the predeterminedperiod of time: transmit a web link to a secure webpage comprising arequest to a user computing device operated by the user, wherein therequest comprises an instruction to populate missing information in theone or more data gaps in the user healthcare profile and execute the oneor more action items; update the user healthcare profile in the seconddatabase upon receiving the information corresponding to the one or moredata gaps from the user computing device; and display one or morehealthcare reports based on evaluation of the data in the one or moredata fields of the user healthcare profile on a graphical user interfaceof the user computing device.

In another embodiment, a computer-implemented method may includereceiving, by a computer, a set of one or more healthcare data recordscontaining a user identifier from one or more healthcare data-generatingsystems configured to generate a corresponding healthcare data record,wherein the one or more healthcare data-generating systems areconfigured to generate the corresponding healthcare data recordaccording to one or more data models associated with one or more formatsand one or more data types. The computer-implemented method may furtherinclude standardizing, by the computer, the set of one or morehealthcare data records received from the one or more healthcaredata-generating systems according to a common data model comprisingmappings specifying transformations from the one or more formats for allhealthcare data records having all of the one or more data types to asingle format and single data type. The computer-implemented method mayfurther include storing, by the computer, the standardized set of one ormore healthcare data records into a first database configured to store aplurality of healthcare data records associated with a plurality of useridentifiers. The computer-implemented method may further includegenerating, by the computer, in a second database, a user healthcareprofile associated with the user identifier, the user healthcare profilecomprising one or more data fields containing data from the standardizedset of one or more healthcare data records associated with the useridentifier in the first database, wherein the second database isconfigured to store a plurality of user healthcare profiles associatedwith a plurality of user identifiers. The computer-implemented methodmay further include identifying, by the computer, one or more data gapscorresponding to missing data in the user healthcare profile associatedwith a user based on examination of data in the one or more data fieldsof the user healthcare profile, wherein the examination comprisesdetermining by the computer a link between data records contained ineach of the one or more data fields. The computer-implemented method mayfurther include upon the computer identifying the one or more data gapsin the user healthcare profile associated with the user when there is nolink between the data records contained in each of the one or more datafields: transmitting, by the computer, a web link to a secure webpagecomprising a request to populate missing information in the one or moredata gaps in the user healthcare profile to a user computing deviceoperated by the user; updating, by the computer, the user healthcareprofile in the second database upon receiving the informationcorresponding to the one or more data gaps from the user computingdevice; and displaying, by the computer, one or more healthcare reportsbased on evaluation of the data in the one or more data fields of theuser healthcare profile on a graphical user interface of the usercomputing device.

In another embodiment, a system may include a first database configuredto store healthcare data records and a second database configured tostore user healthcare profiles. The system may further include acomputer. The computer may be configured to receive a set of one or morehealthcare data records containing a user identifier from one or morehealthcare data-generating systems configured to generate acorresponding healthcare data record, wherein the one or more healthcaredata-generating systems are configured to generate the correspondinghealthcare data record according to one or more data models associatedwith one or more formats and one or more data types. The computer may befurther configured to standardize the set of one or more healthcare datarecords received from the one or more healthcare data-generating systemsaccording to a common data model comprising mappings specifyingtransformations from the one or more formats for all healthcare datarecords having all of the one or more data types to a single format andsingle data type. The computer may be further configured to store thestandardized set of one or more healthcare data records into the firstdatabase configured to store a plurality of healthcare data recordsassociated with a plurality of user identifiers. The computer may befurther configured to generate in the second database a user healthcareprofile associated with the user identifier, the user healthcare profilecomprising one or more data fields containing data from the standardizedset of one or more healthcare data records associated with the useridentifier in the first database, wherein the second database isconfigured to store a plurality of user healthcare profiles associatedwith a plurality of user identifiers. The computer may be furtherconfigured to identify one or more data gaps corresponding to missingdata in the user healthcare profile associated with a user based onexamination of data in the one or more data fields of the userhealthcare profile, wherein the examination comprises determining by thecomputer a link between user actions and sources of data contained inthe one or more data fields. The computer may be further configured toupon the computer identifying the one or more data gaps in the userhealthcare profile associated with the user: transmit a web link to asecure webpage comprising a request to populate missing information inthe one or more data gaps in the user healthcare profile to a usercomputing device operated by the user; update the user healthcareprofile in the second database upon receiving the informationcorresponding to the one or more data gaps from the user computingdevice; and display one or more healthcare reports based on evaluationof the data in the one or more data fields of the user healthcareprofile on a graphical user interface of the user computing device.

It is to be understood that both the foregoing general description andthe following detailed description are exemplary and explanatory and areintended to provide further explanation of the invention as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings constitute a part of this specification andillustrate an embodiment of the invention and together with thespecification, explain the invention.

FIG. 1A shows components of an exemplary healthcare data system,according to an exemplary embodiment.

FIG. 1B shows exemplary data sources of a healthcare data system,according to an exemplary embodiment.

FIG. 2 shows execution of a method for generating healthcare reports andinsights for a user, according to an exemplary embodiment.

FIG. 3A illustrates a graphical user interface showing a webpageexecuted on a computing device of a user, according to an exemplaryembodiment.

FIG. 3B1 illustrates a graphical user interface showing a webpageexecuted on a computing device of a user, according to an exemplaryembodiment.

FIG. 3B2 illustrates a graphical user interface showing a webpageexecuted on a computing device of a user, according to an exemplaryembodiment.

FIG. 3C illustrates a graphical user interface showing a webpageexecuted on a computing device of a user, according to an exemplaryembodiment.

FIG. 3D illustrates a graphical user interface showing a webpageexecuted on a computing device of a user, according to an exemplaryembodiment.

FIG. 3E illustrates a graphical user interface showing a webpageexecuted on a computing device of a user, according to an exemplaryembodiment.

FIG. 3F illustrates a graphical user interface showing a webpageexecuted on a computing device of a user, according to an exemplaryembodiment.

FIG. 3G illustrates a graphical user interface showing a webpageexecuted on a computing device of a user, according to an exemplaryembodiment.

FIG. 3H illustrates a graphical user interface showing a webpageexecuted on a computing device of a user, according to an exemplaryembodiment.

FIG. 3I illustrates a graphical user interface showing a webpageexecuted on a computing device of a user, according to an exemplaryembodiment.

DETAILED DESCRIPTION

The present disclosure is here described in detail with reference toembodiments illustrated in the drawings, which form a part here. Otherembodiments may be used and/or other changes may be made withoutdeparting from the spirit or scope of the present disclosure. Theillustrative embodiments described in the detailed description are notmeant to be limiting of the subject matter presented here.

Reference will now be made to the exemplary embodiments illustrated inthe drawings, and specific language will be used here to describe thesame. It will nevertheless be understood that no limitation of the scopeof the invention is thereby intended. Alterations and furthermodifications of the inventive features illustrated here, and additionalapplications of the principles of the inventions as illustrated here,which would occur to one skilled in the relevant art and havingpossession of this disclosure, are to be considered within the scope ofthe invention.

FIG. 1A shows components of an exemplary healthcare data system 100,which may include a health data service 101, one or more data sources103, and user devices 107. The health data service 101, the data sources103, and the user computing devices 107 are connected to each otherthrough a network 113. The examples of the network 113 may include, butare not limited to, private or public LAN, WLAN, MAN, WAN, and theInternet. The network 113 may include both wired and wirelesscommunications according to one or more standards and/or via one or moretransport mediums. The communication over the network 113 may beperformed in accordance with various communication protocols such asTransmission Control Protocol and Internet Protocol (TCP/IP), UserDatagram Protocol (UDP), and IEEE communication protocols. In oneexample, the network 113 may include wireless communications accordingto Bluetooth specification sets, or another standard or proprietarywireless communication protocol. In another example, the network 113 mayalso include communications over a cellular network, including, e.g. aGSM (Global System for Mobile Communications), CDMA (Code DivisionMultiple Access), EDGE (Enhanced Data for Global Evolution) network. Insome embodiments, all the communication between devices of thehealthcare data system 100 may be performed over secure/HIPAA compliantprotocols/mediums.

The health data service 101 may comprise a data server 109 and one ormore service databases 111. The one or more service databases 111 mayinclude a first database configured to store healthcare data records ofusers and a second database configured to store user healthcare profilesof the users. The first database may include one or more firstsub-databases and each of the one or more first sub-databases may beconfigured to store the healthcare data records of users. The seconddatabase may include one or more second sub-databases and each of theone or more second sub-databases may be configured to store the userhealthcare profiles of the users. In some embodiments, a single databasemay be configured to store the healthcare data records of users and theuser healthcare profiles of the users. The health data server 101 mayreceive data records of various data types over one or more networks 113from the data sources 103; each data source 103 may comprise a datasource device 115 (for example, a healthcare data-generatingsystem/device) and/or a source database 117. In operation, the dataserver 109 of the health data service 101 may receive data from avariety of data sources 103 over the one or more networks 113. The dataserver 109 may then standardize the received data according to a commondata model, and store the standardized health data into a servicedatabase 111. The data server 109 may then execute one or more analyticsprocesses on the standardized health data and provide the standardizedhealth data over the one or more networks 113 to the user device 107that may present health data reports and insights through variousinteractive graphical user interfaces (GUIs) to an end user, inaccordance with the particular function or application executed by theuser computing device 107.

A health data service 101 may receive records from a variety of datasources 103, and may convert the arriving data into a standardized datamodel that may be used to generate various GUIs or used to generatecertain analytical data values resulting from various analyticalalgorithm models executed by a data server 109. In some embodiments, thehealth data service 101 may generate and transmit a request to a user ona user device 107 to receive records, and then the user may provide thehealth data service 101 access to the data sources 103 for obtaining therecords. In some embodiments, the health data service 101 may generateand transmit a request to a user on a user device 107 to receiverecords, and then the user may access the data sources 103 for obtainingthe records, and then transmit the records to the health data service101. The records regarding the individual user/patient may be receivedand/or collected from diverse data sources 103 (as depicted in FIG. 1B)including, but not limited to information from claims through previoushealth plans 103 a, connected devices 103 b, clinical data 103 c, memberdata 103 d, genomics data 103 e, pharmacy data 103 f, physician data 103g, and other sources such as multiple EMR's being used from differentproviders providing care to that user/patient, medication records fromthe pharmacy benefit managers (“PBMs”), information from labs andimaging centers, and direct input by the user/patient to provide aunified personal/individual health record.

In some embodiments, the data collected from the diverse data sources103 is organized into an individual health record for the user/patient.For instance, the data server 109 may generate user healthcare profilerecords for the users that is compiled using the incoming data recordsreceived from the various data sources 103 such as user/patientquestionnaires or direct input, medical devices, patient portals, EMRsystems, claims files, health plans, pharmacy benefits managers, labs,imaging centers, freestanding outpatient facilities, hospitals,physicians, and wearable devices. In some embodiments, the data server109 may receive data records from the various data sources 103 and thenconvert the inbound data from a source data model, of the data source103, to a standardized model employed by the various components of thehealthcare data service 101. In order to convert the incoming datarecords, the data server 109 may execute one or more applicationprogramming interfaces (APIs) that map the data fields of the inbounddata records to the data fields of the standardized model. For instance,records arriving from the data source 103 employing a healthcareapplication (e.g., AllScripts®) may provide inbound records having afirst data model (e.g., HL7). These inbound records would then beconverted by the data server 109 to the standardized model, associatedwith a consumer identifier (consumer ID) and stored into the servicedatabase 111. In one example, the individual healthcare data recordscollected from the variety of data sources 103 by the data server 109may be integrated with universal health care concept codes of thestandardized model to allow the healthcare data records to be encodedunder specific medical diagnostic concepts. In some cases, the dataserver 109 may capture, share, and aggregate the healthcare data recordscollected from the variety of data sources 103 in a consistent manner bythe standardized model universal health care concept codes terminology.The terminology may contain hierarchically specified health careconcepts, each with unique meanings and logic-based definitions.Additionally, the health care concepts may have distinct relationshipsthat support reliability and consistency for healthcare data recordretrieval from the variety of data sources 103. As used herein, theuniversal health care concept codes corresponds to a standardized datamodel language that enables a consistent way of indexing, storing,retrieving, formatting, and aggregating healthcare data record acrossspecialties and sites of medical care obtained from the variety of datasources 103. Each “universal health care concept code” is a uniqueidentifier indicative of a node in a hierarchy of health care conceptsto which other types of healthcare data record obtained from the varietyof data sources 103 can be mapped.

A data server 109 may be any computing device comprising a processor andnon-transitory machine-readable storage media storing software modulesthat instruct the processor to execute the various processes and tasksdescribed herein. Non-limiting examples of the data server 109 mayinclude a workstation computer, a server computer, a laptop, and atablet device. For ease of explanation, FIG. 1 shows a single computingdevice functioning as the data server 109. However, it should beappreciated that some embodiments may comprise any number of the dataservers 109 capable of performing the various tasks described herein.

The data server 109 may receive healthcare data records from varioustypes of data sources 103. The healthcare data records may be log filesor other machine-readable code containing various data fields describingdetected user actions and sources of data associated with a useridentifier. The data server 109 may generate a notification uponreceiving healthcare data records from the data sources 103. The datafields of healthcare data records may contain data fields associatedwith the detected user actions and sources of data associated with theuser identifier, such as data fields describing a source device in thedata sources 103. Upon receiving the healthcare data records, the dataserver 109 or any other server of the system 100 may associate thehealthcare data records with a user account based on the data fields ofthe healthcare data records associated with user identifier. Thehealthcare data records may, for example, contain a data fieldindicating a user identifier value that is unique to the user. The dataserver 109 may then store the healthcare data records into the database111. Simultaneously or at some other time, the data server 109 maygenerate or update a user profile for the user identifier, which is alog file or any other machine-readable code containing data fields thatare populated with data that is based on the healthcare data recordsassociated with the same user identifier. Regardless of the number ofhealthcare data records received for the user identifier from thehealthcare data-generating systems and the data sources 103, thedatabase 111 contains only a single user profile for the particular useridentifier.

In operation, the data server 109 may execute one or more softwaremodules (e.g., APIs, web hooks, and web sprockets) configured to consume(e.g., retrieve/pull, receive), from various data sources 103, inbounddata records that may then be parsed and reconstructed into thestandardized data model format of the healthcare data service 101. Theinterface software modules may be configured to receive or pull datafrom particular data sources 103, as required by the particular datasource 103. In some cases, a data source 103 may be configured totransmit a set of database records at regular interval, using a datatransfer protocol (e.g. FTP, SFTP). Using inbound data records receivedfrom the various data sources 103, the software modules executed by thedata server 109 may generate database records for the service database111. Data models may define the data fields of inbound records and/orthe data fields of the standardized data model, allowing the data server109 to map incoming data models to the standardized data model of thehealthcare data service 101. In some implementations, an inboundinterface software module of the data server 109 may compare certainfields of two inbound data records arriving from disparate data sources103, to determine whether the two inbound records are related to thesame patient. The data server 109 may determine whether a new inboundrecord is related to the same patient of an existing record previouslystored in a service database 111. The data server 109 may execute one ormore analytics algorithms that may perform any number of analyticsalgorithms, such as cross-referencing data, and correlating data, and/orperforming any number of metrics calculations, using data stored in theservice databases 111.

As mentioned, the healthcare data service 101 may comprise one or moreservice databases 111 that may be hosted on one or more computingdevices, such as server computers, workstation computers, laptops,mobile devices, and tablets. The service databases 111 may store datarecords comprising data fields that are associated with particularconsumers or patients, groups of consumers, financial institutions(e.g., insurers), and healthcare providers. In some embodiments, thedata server 109 may parse certain data fields of an inbound record intodistinct records or fields of data records of the service database 111in accordance with the standardized model, as indicated by the executionof the API. It should be appreciated that, although the exemplary system100 shows only one service database 111, however the healthcare dataservice 101 may comprise any number of service databases 111, hosted onany number computing devices, which may be any computing devicecomprising a non-transitory machine-readable storage medium and capableof performing the various tasks described herein.

The data server 109 may be coupled to the data sources 103 via one ormore internal or external networks 113. The data server 109 may executevarious processes on incoming healthcare data records received from thedata sources 103, such as data field formatting or identifying anassociated user and then generating the user profile/record. Each userprofile/record corresponds to a form such as a healthcare form orapplication such as a healthcare application, and contains variousfields that are associated with instances of the form or application.The data server 109 initially populate user profile/record withinformation provided from the user, the one or more healthcaredata-generating systems 115, other records in the data sources 103 oranother source. After the user profile/record is initially populated,the data server 109 assigns status values to the fields in the userprofile/record. The data server 109 may execute instructions to indicatea status of fields in the user profile/record stored in the database111. In some cases, the data server 109 automatically assigns a statusto each field in the user profile/record. To automatically assign statusvalues to fields in the user profile/record, the data server 109compares the data stored in each field to other data associated with theuser. Referring to healthcare record context, for instance, certainfields in the user profile/record may be populated for every userincluding healthcare data collected from the data sources 103. In somecases, the format of the data provided in each field may be defined, forinstance, weight field should include a kilograms. A set of rulesreflecting the format may be obtained by the data server 109 from thedatabase 111. The data server 109 in turn can automatically assignstatus values to fields in the user profile/record based on the rules,for instance, assigning a value of missing data to any field where datais expected and is not there, a status of incorrect data to any fieldwhere the data provided does not conform to an expected value, a statusof incomplete data where data entered is only partial, or by any otherstatus that could be predefined by the data server 109.

In some alternate embodiments, the data server 109 may execute a set ofone or more scenario attribute models on the user profile/record todetermine whether a data gap is present within the user profile/record.Scenario models may be computer files stored on the data server 109 orseparate database device, such as the database 111, and comprise a setof attributes that indicate a type of potential data gap. Upon theexecution of the scenario models, the data server 109 may identify datafield entries in the user healthcare profiles to determine one or morematches to corresponding attributes in the scenario models. In oneexample, the data server 109 upon processing the incoming healthcaredata records of the user may identify a data gap where the data server109 may determine that the user got a referral from a primary caredoctor to see an orthopedic doctor but the data server 109 did notidentify any visit by the user to the orthopedics doctor on processingof the user healthcare data records. In such a case, the data server 109may generate a flag for potential gap or missing information regardingpotential orthopedics doctor visit by the user. In another example case,the data server 109 on processing the incoming healthcare data recordsof the user may identify a data gap where the user is taking amedication for a disease such as high blood pressure, but the dataserver 109 did not identify a doctor visit by the user where the useractually got diagnosed with high blood pressure on processing of theuser healthcare data records. In such a case, the data server 109 maygenerate a flag for potential gap or missing information regardingpotential doctor visit by the user. In yet another example case, thedata server 109 upon processing two or more incoming healthcare datarecords of the user received over a period of time may identify a datagap where the data server 109 may determine a status of update in theuser healthcare condition. For instance, the data server 109 may receivea healthcare data record (in a healthcare form) of a user every month,and then the data server 109 may compare the current healthcare datarecord in the current form with previous healthcare data in previousforms to determine a status update of the user healthcare conditionuser, that is, determining whether the user healthcare condition isbecoming better, worse, or stagnant based on comparison of currenthealthcare data with previous healthcare data. In such a case, the dataserver 109 may generate a flag for potential gap regarding potentialchange in the healthcare condition of the user.

The data server 109 stores the potential gap or missing information inthe database 111 and is used by the data server 109 to determine whatfollow up actions need to be taken. For instance, in some embodiments,the data server 109 may generate an alert upon identifying the potentialgap or missing data in the healthcare data records. In some embodiments,the data server 109 may determine how to obtain the required data orgenerate requests for confirmations of the missing data from the user.In some embodiments, another server of a centrally hosted the system 100receives a notification of status information from the data server 109specifying relevant missing data fields and/or records, the status ofthe data fields, and how the missing information should be recovered.The notification may provide that several different data sources 103need to be queried for missing information, for instance, differenthealthcare data-generating systems 115 or users, if the informationresides in different places. The data server 109 issues requests to allthe different sources of data, such as different healthcaredata-generating systems 115, and thereby minimizing the hassle for theuser to provide missing information.

In some embodiments, the data server 109 queries the differenthealthcare data-generating systems 115 and other data sources 103 on aregular basis or in response to indication of missing data, andretrieves information about missing records that require follow upaction. In some cases, the data server 109 uses the status of themissing information to generate a request to be sent to a user computingdevice 107, based on instructions from the user, stored in the database111. In some embodiments, the data server 109 solicits missinginformation electronically, through an email, chat, or other request.The request may be automatically formulated and sent by the data server109 or may be created and provided to the user computing device 107through an interface for verification before sending. The request mayinclude a web link to a secure webpage or a data object that can bepopulated, saved, and returned to the data server 109. For example, thewebpage contains the missing data fields and spaces to fill in themissing data. The webpage may be provided with options for communicatingwith the data server 109, for instance, including by sending an emailmessage or initiating a chat. The webpage may further include variouslinks to information about the requested data, and an option to providea comment for any of the missing data fields. In some other instances,the request may solicit a response from a user computing device 107 inthe form of a return email. In some other embodiments, the data server109 can also transmit the request by email, phone, fax, mail, or otherconventional means to the user computing device 107. The data server 109may include computer software for formulating a request coupled to anoutput interface for transmitting the request to the user computingdevice 107. In the case of a request transmitted to the user computingdevice 107, a textual or voice messaging capabilities may be used toformulate a message. The message may solicit a touch-tone response whichis detected and recorded by the data server 109, or a verbal responsethat is recorded by the data server 109. In some embodiments, if theuser does not respond within a predetermined period of time or aresponse is incomplete or prompts further inquiry, a reminder orfollow-up request may be provided to the user computing device 107. Oncethe correct and accurate data for missing field has been supplied by theuser computing device 107, the data server 109 may remove any missingdata tag from the user healthcare record, and update the user healthcareprofile with information provided by the user in response to the requestfor missing data and store in the database 111. Additional calculationsor assessments by the data server 109 may be performed based oninformation stored in the updated healthcare database record of the userstored in the database 111. Once the healthcare database record of theuser is complete and accurate, the data server 109 may output theapplication or form corresponding to the user healthcare record toanalytical engine of the system 100 for further processing. In someembodiments, the analytical engine or the data server 109 may apply oneor more analytical models and/or algorithms on the healthcare record ofthe user stored in the database 111 to calculate healthcare reports andinsights for the user. For example, the analytical models and/oralgorithms executed by the analytical engine or the data server 109 mayclassify the information sources into categories that may be related tothe type and origin of the healthcare information source, and thenidentify the relationships between collected healthcare informationdocuments and generate corresponding insights such as clinical summaryand health timeline of the user for a pre-defined interval of time.

Data Sources 103 may include any number of computing devices ormachine-readable computer files providing the healthcare data service101 with inbound data records in any number of data formats and datatypes. For example, a data source 103 may be a healthcare applicationserver 115 that generates healthcare records (i.e., inbound records,EHR) according to the particular data model of the healthcareapplication (e.g., AllScripts®, EPIC®, MatrixCare®, AOD®, eHealthcare®).In some cases, the inbound records may be transmitted to a data server109 of the healthcare data service 101 over any number of internal andexternal data networks 113. As another example of a data source 103, theinbound data records may be scanned from paper documents and transmittedto a data server 109 of the healthcare data service 101. As anotherexample, a data source 103 may include a data repository 117 storingrecords according to any number of data formats (e.g., XML, JSON, RSS,SQL, text file, RSS) and/or data models (e.g., HL7, CCD, Delta,customized model), and may be transmitted to a data server 109 of thehealthcare data service 101 or may be fetched by the data server 109 ofthe healthcare data service 101 based on a triggering condition (e.g.,time-based periodic updates, real-time updates). In some cases, a datasource 103 may include a financial institution, such as a healthinsurance provider, storing records of claim events, claim history,financial insured coverage, and the like, in a format of the financialinstitution. Additionally or alternatively, in some cases a data source103 may include an end-user device 107 that may generate and transmithealthcare data to the healthcare data service 101. For example, in someinstances, a data source 103 may include a wearable fitness tracker thatmay generate data records associated with fitness and motion activity ofthe consumer during periods of physical activity. This data may beprovided from the wearable data source 103 to data server 109 and/orservice database 111.

The data sources 103 may include any number of healthcare applicationservers 115 executing healthcare applications that generate electronichealthcare records having a prescribed data model associated with theparticular healthcare application. In some instances, the data sources103 may include a data repository 117 containing healthcare recordsstored in an electronic format on one or more servers, or othernon-transitory machine-readable storage media. A data source 103 may beconfigured to provide inbound records to the healthcare data service 101in any number of ways. For example, in some cases, a data repository 123may be configured to periodically (e.g., daily) transmit via a datatransfer protocol (e.g., FTP, SFTP).

A user device 107 may be any computing device comprising a processorconfigured to execute a healthcare application or a web browserapplication that accesses or receives data records from the healthcaredata service 101. Non-limiting examples of the user device 107 mayinclude a server computer, a workstation computer, a wearable device, atablet device, and a mobile device (e.g., smartphone, PDA). In someinstances, the user device 107 may execute a client-side healthcareapplication for manipulating or updating patient data stored in aservice database 111. For example, a consumer may use a tablet device131 configured to access the records that they have been granted accessto, and having a predefined data model. The data server 109 maystructure and output to the user device 107 portions of the requestedpatient data stored in the databases 111 according to the particularfunction requested by the user device 107.

In some embodiments, the user device 107 may be any computing and/ortelecommunications device capable of performing the various tasks andprocesses described herein, such as accessing a webserver (not shown)and providing a GUI interface to a user to interact with acustomer-centric website hosted on the webserver. In other words, theuser device 107 may allow the user to interact with the data server 109via the webserver. The user device 107 may execute an Internet browseror local application that access the webserver in order to issuerequests or instructions to the data server 109 to access the system100. The user device 107 may transmit credentials from user inputs tothe webserver, from which the webserver may authenticate the user. Onehaving skill in the art would appreciate that the user device 107 maycomprise any number of input devices configured to receive any number ofdata inputs (e.g., mouse, keyboard, touchscreen, stylus), includingvarious types of data inputs allowing for authentication, e.g.,username, passwords, certificates, biometrics. One having skill in theart would also appreciate that the user device 107 may be any computingdevice comprising a processor and non-transitory machine-readablestorage medium allowing the user device 107 to perform the various tasksand processes described herein.

As an example of the user device 107 operation, the user device 107 mayexecute an Internet browser that accesses the webserver hosting awebsite and/or healthcare application that allows for the user to accessto the consolidated healthcare data and reports. Using the user device107, a user may interact with various data published on the user-centricwebsite and/or healthcare application. The user device 107 of the usermay be used upload machine-readable computer files (e.g., PDF, DOC, XSL)containing healthcare and insurance information. The computer files maybe stored into document records in the service database 111. The userdevice 107 may issue queries or instructions to the data server 109 viathe webpages generated by the webserver, which then instruct the dataserver 109 to perform various tasks, such as retrieving or updating afile from the service database 111.

A webserver (not shown) may be any computing device hosting a websiteand/or healthcare application accessible to the user device 107 via theInternet. The webserver may be any computing device comprising aprocessor and non-transitory machine-readable storage capable ofexecuting the various tasks and processes described herein. Non-limitingexamples of such computing devices may include workstation computers,laptop computers, server computers, laptop computers, and the like.While the exemplary system 100 includes a single webserver, one havingskill in the art would appreciate that in some embodiments the webservermay include any number of computing devices operating in a distributedcomputing environment.

The webserver may execute software applications configured to host thewebsite (e.g., Apache®, Microsoft IIS®) and/or healthcare application,which may generate and serve various webpages to the user device 107.The website and/or healthcare application may be used to generate andaccess data stored on the service database 111. In some implementations,the webserver may be configured to require user authentication basedupon a set of user authorization credentials (e.g., username, password,biometrics, cryptographic certificate). In such implementations, thewebserver may access the service database 111 configured to store usercredentials, which the webserver may be configured to reference in orderto determine whether a set of entered credentials purportedlyauthenticating the user match an appropriate set of credentials thatidentify and authenticate the user. Similarly, in some implementations,the webserver may generate and serve webpages to the user device 107based upon user membership specifics within the system 100. In suchimplementations, the user profile may be defined by data fields in userrecords stored in the service database 111, and authentication of theuser may be conducted by the webserver by executing an access directoryprotocol. The webserver may then be instructed to generate webpageand/or healthcare application content, access or generate data stored inthe service database 111, according to the user membership specificsdefined by the user record in the service database 111.

Service databases 111 may be hosted on any server (such as a data server109) and are capable of storing the user healthcare records and userhealthcare profiles in plain format and/or encrypted version containingdata fields that are associated with the communication channel and typeof healthcare data-generating systems. The service databases 111 mayfurther store user records that may comprise data fields describingusers, e.g., user data, such as user credentials (e.g., username,passwords, biometrics, encryption certificates), user account data, userrules, or user permissions; document records that may comprisemachine-readable computer files (e.g., word processing files), parsedportions of such computer files, or metadata associated with computerfiles; and application data that may include software instructionsexecuted by the data server 109 or data used by the such applicationsexecuted by the data server 109. The service databases 111 may be incommunication with a processor of the data server 109, where theprocessor is capable of executing the various commands of the system100. In some embodiments, the service databases 111 may be part of thedata server 109. In some embodiments, the service databases 111 may be aseparate component in communication with the data server 109.

The service databases 111 may be in communication to the data server 109via the network 113 and include a non-transitory machine-readablestorage media capable of receiving, storing, updating healthcare recordsstored in the service databases 111. The service databases 111 may havea logical construct of data files that are stored in non-transitorymachine-readable storage media, such as a hard disk or memory,controlled by software modules of a database program (for example, SQL),and a related database management system (DBMS) that executes the codemodules (for example, SQL scripts) for various data queries and othermanagement functions generated by the data server 109.

In some embodiments, a memory of the service databases 111 may be anon-volatile storage device for storing alert element data andinstructions, to be used by a processor of the data server 109. Thememory may be implemented with a magnetic disk drive, an optical diskdrive, a solid-state device, or an attachment to a network storage. Thememory may include one or more memory devices to facilitate storage andmanipulation of program code, set of instructions, tasks, data, PDKs,and the like. Non-limiting examples of memory implementations mayinclude, but are not limited to, a random access memory (RAM), a readonly memory (ROM), a hard disk drive (HDD), a secure digital (SD) card,a magneto-resistive read/write memory, an optical read/write memory, acache memory, or a magnetic read/write memory.

In some embodiments, a memory of the service databases 111 may be atemporary memory, meaning that a primary purpose of the memory is notlong-term storage. Examples of the volatile memories may include dynamicrandom access memories (DRAM), static random access memories (SRAM), andother forms of volatile memories known in the art. In some embodiments,the memory may be configured to store larger amounts of information thanvolatile memory. The memory may further be configured for long-termstorage of information. In some examples, the memory may includenon-volatile storage elements. Examples of such non-volatile storageelements include magnetic hard discs, optical discs, floppy discs, flashmemories, or forms of electrically programmable memories (EPROM) orelectrically erasable and programmable (EEPROM) memories.

The healthcare data system 100 described herein, provide a number ofadvantages over the existing applications. The healthcare data system100 provides an agnostic system that is able to implementinteroperability of discrete medical records. In other words, thehealthcare data system 100 can free health care information for eachpatient without the need to standardize the already existing industrypractice. Instead of implementing standardization of data management,the healthcare data system 100 and process described herein canefficiently and accurately provide any one health care provider theability to obtain a comprehensive and accurate record for each patient.The applications for such information are endless and can be applicablenot only in the long term health care industry, where the problem ofdisparate data sources is most prevalent, but can also improve theinformation management in the acute health care practice. The healthcaredata system 100 and methods described herein are able to make availablea complete patient record to any device independent of the data systeminvolved, including any desired mobile applications, allow the user torun any number of analytics, identify key performance indicators, andview the information in any number of different display modes.

FIG. 2 shows execution steps of generating healthcare reports andinsights for a user, according to an exemplary method 200. The exemplarymethod 200 shown in FIG. 2 comprises execution steps 202, 204, 206, 208,210, 212, and 214. However, it should be appreciated that otherembodiments may comprise additional or alternative execution steps, ormay omit one or more steps altogether. It should also be appreciatedthat other embodiments may perform certain execution steps in adifferent order; steps may also be performed simultaneously ornear-simultaneously with one another. In addition, the exemplary method200 of FIG. 2 is described as being executed by a single healthcareserver computer in this exemplary embodiment. However, one having skillin the art will appreciate that, in some embodiments, steps may beexecuted by any number of computing devices operating in a distributedcomputing environment. In some cases, a computer executing one or moresteps may be programmed to execute various other, unrelated features,where such computer does not need to be operating strictly as thehealthcare server computer described herein.

In a first step 202, a healthcare server computer may receive a set ofone or more healthcare data records containing a user identifier fromone or more healthcare data-generating systems and data sources. Thehealthcare server may handle the healthcare data records based at leastin part by configuring the one or more healthcare data-generatingsystems to subscribe to a data feed of healthcare information. In someembodiments, the data feed may be adapted to collect healthcareinformation in RSS format, OPML format, or other formats from the one ormore healthcare data-generating systems such as fitness wearabledevices, connected devices for weight tracking, connected devices formedical tracking, hospital data-generating systems, pharmacydata-generating systems, medical device, medical instrument, handheldmedical device, a device associated with an operating room, a deviceconfigured to display an electronic medical record, a device configuredto run a healthcare software application, and the like. In someembodiments, the healthcare data record may contain information selectedfrom a group including, but not limited to, medical instruments, x-rayequipment, MRI equipment, other forms of medical imaging equipment,blood work data, genetic information, medical exam information, medicaldevice information, information from emergency rooms, information frommedical labs, diet information, exercise information, metabolicinformation, medical history information, age information, genderinformation, behavior information, race information, or information fromother systems related to the healthcare and or medical field.

The one or more healthcare data-generating systems are typicallyconfigured to generate corresponding healthcare data record according toone or more data models associated with one or more formats and one ormore data types. Each of the one or more healthcare data-generatingsystems may be configured to generate the corresponding healthcare datarecord according to a separate type of data model having a separate datatype and a separate data format.

In a next step 204, the healthcare server computer standardize the setof one or more healthcare data records received from the one or morehealthcare data-generating systems according to the one or more datamodels according to a common data model. The healthcare server computermay standardize the set of one or more healthcare data records havingthe one or more formats and the one or more data types by mapping thetransformation of the one or more formats for all healthcare datarecords having all of the one or more data types to a single format andsingle data type. In some embodiments, the healthcare server computermay select the healthcare server computer based on recommendation of theuser. In some embodiments, the healthcare server computer may select thehealthcare server computer based on configuration of a user computingdevice.

Upon standardizing the set of one or more healthcare data recordsreceived from the one or more healthcare data-generating systemsaccording to the common data model, the healthcare server computer maythen store the standardized set of the one or more healthcare datarecords into the first database. The first database may store aplurality of healthcare data records associated with a plurality of useridentifiers.

In a next step 206, the healthcare server computer generate, in a seconddatabase, a user healthcare profile associated with the user identifierbased on the standardized set of the one or more healthcare data recordsstored in the first database. The user healthcare profile may includeone or more data fields containing data from the standardized set of oneor more healthcare data records associated with the user identifier inthe first database. For instance, the user profile may includeinformation such as heart rate, pulse rate, beat-to-beat heartvariability, EKG or ECG, respiration rate, skin temperature, core bodytemperature, heat flow off the body, EMG, EEG, EOG, blood pressure, bodyfat, hydration level, activity level, oxygen consumption, glucose orblood sugar level, body position, pressure on muscles or bones, and UVradiation absorption. The second database is configured to store aplurality of user healthcare profiles associated with a plurality ofuser identifiers.

In some embodiments, upon the creation of the user healthcare profile,the healthcare server computer may determine one or more action itemsassociated with the data in each of the one or more data fields in theuser healthcare profile. Each action item may be programmed and/orscheduled to be performed within a predetermined period of time. Thehealthcare server computer may then determine the predetermined periodof time during which each of the one or more action items has to beexecuted by the user. Upon the determination of the one or more actionitems to be executed by the user within the predetermined period oftime, the healthcare server computer is then configured to trigger amonitoring window for a time period to measure the time period from thedetermination of the one or more action items until the predeterminedperiod of time elapses for each of the one or more action items. Duringthe monitoring window, the healthcare server computer periodicallychecks whether a record of execution of each of the one or more actionitems by the user is either available from the one or more healthcaredata-generating systems or has been received in an internal databasefrom the one or more healthcare data-generating systems/user. In oneexample case, the healthcare server computer on processing the data ineach of the one or more data fields in the user healthcare profile mayidentify a record indicating a referral for a user to visit a doctor ona certain date and time. For instance, a healthcare server computer maydetermine on Jan. 20, 2016 that a record in the user healthcare profileindicates that a doctor A on Jan. 15, 2016 referred the user to visit adoctor B, which is most likely to occur by Mar. 15, 2016. Then thehealthcare server computer may trigger a monitoring window and/or atimer to track the visit of the user to the doctor B. The healthcareserver computer may monitor the visit of the user to doctor B until Mar.15, 2016. On Mar. 16, 2016, the healthcare server computer may check aninternal database to determine whether any record of user visit to thedoctor B prior to Mar. 15, 2016 has been received from the one or morehealthcare data-generating systems. In some instances, the healthcareserver computer upon determining that no record of the user visit to thedoctor B prior to Mar. 15, 2016 is available in the internal database,which may be represented as a gap in the record, so the healthcareserver computer may generate a request corresponding to a confirmationresponse for verification of the user visit to the doctor B prior toMar. 15, 2016. The healthcare server computer then transmits the requestto the one or more healthcare data-generating systems. The one or morehealthcare data-generating systems upon receiving the request maytransmit a message to the healthcare server computer regarding whetherthere exists a record of the user visit to the doctor B prior to Mar.15, 2016 or not.

In a next step 208, the healthcare server computer identify one or moredata gaps corresponding to missing data in the user healthcare profileassociated with a user based on examination of data in the one or moredata fields of the user healthcare profile. In some embodiments, theexamination of the data by the healthcare server computer may correspondto determination by the healthcare server computer whether there is anyrecord of execution of the one or more action items by the user withinthe predetermined period of time. The healthcare server computer maylocate the record of the execution of the one or more action items inthe internal database or request the record from the one or morehealthcare data-generating systems. In some embodiments, the examinationof data in the one or more data fields of the user healthcare profilemay include determining by the computer a link between user actions andsources of data contained in the one or more data fields. In someembodiments, the examination of data in the one or more data fields ofthe user healthcare profile may include determining by the computer alink between all the data contained in each of the one or more datafields. For example, the healthcare server computer on processing thehealthcare data records in the user healthcare profile may identify adata gap where the healthcare server computer may determine that theuser got a referral from a primary care doctor to see an orthopedicsdoctor but the healthcare server computer did not identify any visit bythe user to the orthopedics doctor on processing of the user healthcaredata records. In such a case, the healthcare server computer maygenerate a flag for potential gap or missing information regardingpotential orthopedics doctor visit by the user. In another example case,the healthcare server computer on processing the healthcare data recordsin the user healthcare profile may identify a data gap when a user istaking a medication for a disease such as high blood pressure, but thehealthcare server computer did not identify a doctor's visit by the userwhere the user actually got diagnosed with high blood pressure onprocessing of the user healthcare data records. In such a case, thehealthcare server computer may generate a flag for potential gap ormissing information regarding potential doctor visit by the user. Thehealthcare server computer stores the potential gap or missinginformation in the database and is used by the healthcare servercomputer to determine what follow up actions need to be taken.

In a next step 210, the healthcare server computer upon identifying theone or more data gaps in the user healthcare profile associated with theuser because there is no record of execution of the one or more actionitems within the predetermined period of time, may then generate arequest for a user to execute the one or more action items. Thehealthcare server computer may provide the user with informationcorresponding to the one or more action items within the request. Theinformation may include a new deadaline date and time schedule toexecute the one or more action items. In some instances, the healthcareserver computer may communicate (through wired or wireless communicationplatform) with the one or more healthcare data-generating systems todetermine the new deadline date and time schedule for the user toexecute the one or more action items.

In some embodiments, the healthcare server computer upon identifying theone or more data gaps in the user healthcare profile associated with theuser may generate a request to complete the data gaps in the healthcaredatabase record. The healthcare server computer may transmit the requestto an user computing device operated by the user in order to provideinformation corresponding to the one or more data gaps in the userhealthcare profile. In some embodiments, the healthcare server computermay request the user computing device for additional information bypopulating fields marked as incomplete or missing in a webpage displayedon the user computing device as part of the request. In someembodiments, if the user does not respond within a predetermined periodof time or a response is incomplete or prompts further inquiry, areminder or follow-up request may be provided to the user computingdevice by the healthcare server computer.

In a next step 212, the healthcare server computer update the userhealthcare profile in the second database upon receiving the informationcorresponding to the one or more data gaps from the user computingdevice. In some embodiments, additional calculations or assessments bythe healthcare server computer may be performed based on informationstored in the updated healthcare database record of the user stored inthe database. Once the healthcare database record of the user iscomplete, the healthcare server computer may output process the datawithin the healthcare database record to generate healthcare reports andinsights.

In a next step 214, the healthcare server computer display the one ormore healthcare reports and insights based on evaluation of the data inthe one or more data fields of the user healthcare profile on agraphical user interface of the user computing device. The one or morehealthcare reports and insights may include ovulation report based onanalysis of skin temperature, core temperature, and oxygen consumptionobtained from the user healthcare profile; sleep onset/wake report basedon analysis of heart rate, pulse rate, and respiration data obtainedfrom the user healthcare profile; calories burned report based onanalysis of heart rate, pulse rate, respiration rate, heat flow,activity, and oxygen consumption data obtained from the user healthcareprofile; metabolic rate report based on analysis of heart rate, pulserate, respiration rate, heat flow, activity, and oxygen consumption dataobtained from the user healthcare profile; and activity level reportbased on heart rate, pulse rate, respiration rate, heat flow; stresslevel report based on analysis of heart rate, pulse rate, respirationrate, skin temperature, heat flow, galvanic skin; and relaxation levelreport based on EKG, beat-to-beat variability, heart rate, and pulserate data obtained from the user healthcare profile.

FIG. 3A illustrates a graphical user interface 300 showing a webpage 302executed on a computing device of a user, according to an exemplaryembodiment. In some embodiments, the computing device may be anyportable or non-portable device, such as a desktop computer, a laptopcomputer, a tablet computer, a smart phone, a smart watch, a gamingconsole, a personal digital assistant, or the like. The computing devicemay include a processor/microcontroller and/or any other electroniccomponent that performs one or more operations according to one or moreprogramming instructions. The computing device may be capable ofcommunicating with a system server through a communications networkusing wired or wireless communication capabilities.

A healthcare management application may be installed on the computingdevice of the user or may be configured to display on a website of ahealthcare company. In some embodiments, a healthcare managementapplication is installed on a computing device of an employer, aprovider, and/or a payer. For example, a healthcare company may generatethe healthcare application as a widget configured to communicate withdifferent users, employers, providers, and payers and the widget may bedisplayed on the website of the healthcare company. A computing devicemay have access to one or more databases or pre-stored web-basedinterfaces, such as webpages, comprising a number of preconfiguredsub-interfaces, or containers, that are dynamically populated (e.g.,widget box). For example, healthcare application webpages may containcode, such as HTML or PHP, presenting a website of any number ofwebpages having a common look-and-feel. One or more outputs or resultsmay display webpages 302 that may contain additional code forcontainers, where the container code displays the healthcare applicationwidget. A user may access a webpage 302 and interact with the computingdevice via the healthcare application. In some implementations, thecomputing device may be configured to require user authentication basedupon a set of user authorization credentials (e.g., username, password,biometrics, cryptographic certificate) to provide access to thehealthcare application on the computing device. For example, thecomputing device may access a database configured to store the usercredentials, which a webserver may be configured to reference in orderto determine whether a set of entered credentials purportedlyauthenticating the user match an appropriate set of credentials thatidentify and authenticate the user. Similarly, in some implementations,the webserver may generate and serve applications/webpages associated tothe healthcare application to the computing device based upon a usermembership account. In some embodiments, the webserver may generate andserve applications/webpages associated to the healthcare application(such as the webpage 302) to the computing device based upon the usermembership. In such implementations, the user membership may be definedby data fields in the user records stored in the database, andauthentication of the user and the user membership may be conducted bythe webserver by executing an access directory protocol.

During operation, a user may access the webpage 302 by any common accessmethod, e.g., keying in a URL, selecting from search results, etc., andsubmit user credentials to access the healthcare application. Upon thewebserver authenticating the user using credentials that identify theuser as a valid member of the healthcare application company, the useris presented the healthcare application. For instance, the healthcareapplication may be a description window that may provide informationregarding creating an account (via SIGN UP button) 304. If the useralready has an account, the user may click “LOGIN” button 306 on thehealthcare application to access their account by providing the emailaddress and the password information.

FIG. 3B1 illustrates a graphical user interface 308 showing a webpageexecuted on a computing device of a user, according to an exemplaryembodiment. A healthcare management application may be installed on thecomputing device of the user. In some embodiments, a healthcaremanagement application is installed on a computing device of anemployer, provider, and/or payer. Upon registering an account with ahealthcare management application, the user may select a tab 310 toconnect one or more wearable devices that track sleep, fitness, andnutrition of the user with a healthcare management application. Upon thesynchronization of the one or more wearable devices with the healthcaremanagement application, a server of the healthcare managementapplication may receive health data 312 such as a number of steps of theuser in a given day, a number of calories burned of the user in a givenday, blood pressure of the user, heart rate of the user, among otherinformation.

In some embodiments, the one or more wearable devices may include anearpiece, gown, wristband, or other such structures for positioning oneor more modules configured to communicate in a vicinity of a user whowears the structure(s). Other embodiments may be configured tocommunicate with a stationary or other module and/or to include one ormore sensors for detecting status indicia relating to the user. The oneor more wearable devices may preferably be worn by an individual user onhis or her body. The one or more wearable devices may be adapted togenerate signals in response to physiological characteristics of theuser and a microprocessor. In some cases, the one or more wearabledevices may generate data indicative of various physiological parametersof the user, such as the user's heart rate, pulse rate, beat-to-beatheart variability, EKG or ECG, respiration rate, skin temperature, corebody temperature, heat flow off the body, galvanic skin response or GSR,EMG, EEG, EOG, blood pressure, body fat, hydration level, activitylevel, oxygen consumption, glucose or blood sugar level, body position,pressure on muscles or bones, and UV radiation absorption. In certaincases, the data indicative of the various physiological parameters ofthe user is the signal or signals themselves generated by the one ormore wearable devices and in certain other cases the data is calculatedby the microprocessor based on the signal or signals generated by theone or more wearable devices.

In some embodiments, a server of the healthcare management applicationmay be programmed to summarize and analyze the data received from theone or more wearable devices. For example, the server can be programmedto calculate an average, minimum or maximum rate such as heart rate orrespiration rate over a defined period of time.

In some embodiments, the one or more wearable devices may include one ormore sensor devices that may generate data indicative of variouscontextual parameters relating to the environment surrounding the user.For example, the sensor device can generate data indicative of the airquality, sound level/quality, light quality or ambient temperature nearthe user. The sensor device may include a processor for generatingsignals in response to contextual characteristics relating to theenvironment surrounding the user and the signals may be used to generatethe healthcare data record of the user.

FIG. 3B2 illustrates a graphical user interface 313 showing a webpageexecuted on a computing device of a user, according to an exemplaryembodiment. A healthcare management application may be installed on thecomputing device of the user. In some embodiments, a healthcaremanagement application is installed on a computing device of anemployer, provider, and/or payer. Upon registering an account with ahealthcare management application, the user may provide clinical recordauthorization. For instance, the user may authorize a processor of thehealthcare management application to connect to one or more clinics andone or more physicians of the user and obtain the records associatedwith the user.

FIG. 3C illustrates a graphical user interface 314 showing a webpageexecuted on a computing device of a user, according to an exemplaryembodiment. A healthcare management application may be installed on thecomputing device of the user. In some embodiments, a healthcaremanagement application is installed on a computing device of anemployer, provider, and/or payer. The healthcare management applicationaccount of the user displayed on the graphical user interface 314 maydisplay a healthcare profile of the user that may include informationsuch as health journey of the user, one or more connected sources to thehealthcare management application, user health records (My Health), andfinancial data of the user collected from various data sources.

FIG. 3D illustrates a graphical user interface 316 showing a webpageexecuted on a computing device of a user, according to an exemplaryembodiment. A healthcare management application may be installed on thecomputing device of the user. In some embodiments, a healthcaremanagement application is installed on a computing device of anemployer, provider, and/or payer. The healthcare management applicationaccount of the user displayed on the graphical user interface 316 mayprovide an option to the user to add one or more family membershealthcare data.

FIG. 3E illustrates a graphical user interface 318 showing a webpageexecuted on a computing device of a user, according to an exemplaryembodiment. A healthcare management application may be installed on thecomputing device of the user. In some embodiments, a healthcaremanagement application is installed on a computing device of anemployer, provider, and/or payer. Upon registering an account with ahealthcare management application, the user may select a tab 320 toconnect with one or more insurance plans that track of benefits, claimshistory, and financial such as out of pocket and deductibles. Upon thesynchronization of the one or more insurance plans with the healthcaremanagement application, the server of the healthcare managementapplication may receive insurance data such as benefits information andclaim information. In some embodiments, a server of the healthcaremanagement application may be programmed to summarize and analyze thedata received from the one or more insurance plans.

FIG. 3F, FIG. 3G, FIG. 3H, and FIG. 3I illustrates a graphical userinterface 322 showing a webpage executed on a computing device of auser, according to an exemplary embodiment. A healthcare managementapplication may be installed on the computing device of the user. Insome embodiments, a healthcare management application is installed on acomputing device of an employer, provider, and/or payer. The healthcaremanagement application account of the user displayed on the graphicaluser interface 322 may provide one or more healthcare reports generatedbased on analysis of healthcare data of the user collected from multipledata sources and data generating systems. The one or more healthcarereports may include a tab for clinical summary 324, a tab for my fitness326, a tab for health timeline 328, and a tab for labs 330. The userupon selecting the tab for clinical summary 324 may display informationsuch as care needs, allergies, diagnosis, medications, and surgeries.The user upon selecting the tab for my fitness 326 may displayinformation such as number of steps taken by the user, number ofcalories burned by the user, blood pressure of the user, heart rate ofthe user, and weight of the user. The user upon selecting the tab forthe health timeline 328 may be able to view completed health assessment.The user upon selecting the tab for labs 330 may be able to view labresults such as for glucose, cholesterol, etc.

The various illustrative logical blocks, modules, circuits, andalgorithm steps described in connection with the embodiments disclosedherein may be implemented as electronic hardware, computer software, orcombinations of both. To clearly illustrate this interchangeability ofhardware and software, various illustrative components, blocks, modules,circuits, and steps have been described above generally in terms oftheir functionality. Whether such functionality is implemented ashardware or software depends upon the particular application and designconstraints imposed on the overall system. Skilled artisans mayimplement the described functionality in varying ways for eachparticular application, but such implementation decisions should not beinterpreted as causing a departure from the scope of the presentinvention.

Embodiments implemented in computer software may be implemented insoftware, firmware, middleware, microcode, hardware descriptionlanguages, or any combination thereof. A code segment ormachine-executable instructions may represent a procedure, a function, asubprogram, a program, a routine, a subroutine, a module, a softwarepackage, a class, or any combination of instructions, data structures,or program statements. A code segment may be coupled to another codesegment or a hardware circuit by passing and/or receiving information,data, arguments, parameters, or memory contents. Information, arguments,parameters, data, etc. may be passed, forwarded, or transmitted via anysuitable means including memory sharing, message passing, token passing,network transmission, etc.

The actual software code or specialized control hardware used toimplement these systems and methods is not limiting of the invention.Thus, the operation and behavior of the systems and methods weredescribed without reference to the specific software code beingunderstood that software and control hardware can be designed toimplement the systems and methods based on the description herein.

When implemented in software, the functions may be stored as one or moreinstructions or code on a non-transitory computer-readable orprocessor-readable storage medium. The steps of a method or algorithmdisclosed herein may be embodied in a processor-executable softwaremodule which may reside on a computer-readable or processor-readablestorage medium. A non-transitory computer-readable or processor-readablemedia includes both computer storage media and tangible storage mediathat facilitate transfer of a computer program from one place toanother. A non-transitory processor-readable storage media may be anyavailable media that may be accessed by a computer. By way of example,and not limitation, such non-transitory processor-readable media maycomprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage,magnetic disk storage or other magnetic storage devices, or any othertangible storage medium that may be used to store desired program codein the form of instructions or data structures and that may be accessedby a computer or processor. Disk and disc, as used herein, includecompact disc (CD), laser disc, optical disc, digital versatile disc(DVD), floppy disk, and blu-ray disc where disks usually reproduce datamagnetically, while discs reproduce data optically with lasers.Combinations of the above should also be included within the scope ofcomputer-readable media. Additionally, the operations of a method oralgorithm may reside as one or any combination or set of codes and/orinstructions on a non-transitory processor-readable medium and/orcomputer-readable medium, which may be incorporated into a computerprogram product.

The preceding description of the disclosed embodiments is provided toenable any person skilled in the art to make or use the presentinvention. Various modifications to these embodiments will be readilyapparent to those skilled in the art, and the generic principles definedherein may be applied to other embodiments without departing from thespirit or scope of the invention. Thus, the present invention is notintended to be limited to the embodiments shown herein but is to beaccorded the widest scope consistent with the following claims and theprinciples and novel features disclosed herein.

While various aspects and embodiments have been disclosed, other aspectsand embodiments are contemplated. The various aspects and embodimentsdisclosed are for purposes of illustration and are not intended to belimiting, with the true scope and spirit being indicated by thefollowing claims.

What is claimed is:
 1. A computer-implemented method comprising:receiving, by a computer, a set of one or more healthcare data recordscontaining a user identifier from one or more healthcare data-generatingsystems configured to generate a corresponding healthcare data record,wherein the one or more healthcare data-generating systems areconfigured to generate the corresponding healthcare data recordaccording to one or more data models associated with one or more formatsand one or more data types; standardizing, by the computer, the set ofone or more healthcare data records received from the one or morehealthcare data-generating systems according to a common data modelcomprising mappings specifying transformations from the one or moreformats for all healthcare data records having all of the one or moredata types to a single format and single data type; storing, by thecomputer, the standardized set of one or more healthcare data recordsinto a first database configured to store a plurality of healthcare datarecords associated with a plurality of user identifiers; generating, bythe computer, in a second database, a user healthcare profile of a userassociated with the user identifier, the user healthcare profilecomprising one or more data fields containing data from the standardizedset of one or more healthcare data records associated with the useridentifier in the first database, wherein the second database isconfigured to store a plurality of user healthcare profiles associatedwith a plurality of user identifiers, and wherein each user healthcareprofile contains one or more action items associated with data in eachof the one or more data fields; determining, by the computer, that theuser healthcare profile contains a first record of a first action itemthat requires entry of a second record indicating that a second actionitem has been performed, wherein the second record of the second actionitem is programmed to require a record of execution within apredetermined period of time; determining, by the computer, that thepredetermined period of time has elapsed; responsive to determining thatthe predetermined period of time has elapsed, determining whether arecord of execution of the second action item is available from the oneor more healthcare data-generating systems after the predeterminedperiod of time elapses, wherein the computer is configured to trigger amonitoring window for a time period from determination of the firstaction item until the predetermined period of time elapses to determinethe execution of the second action item; identifying, by the computer,one or more data gaps corresponding to missing data in the userhealthcare profile based on a link between the first data record for thefirst action item and the second data record for the second action itemand when the second record does not contain the record of execution ofthe second action item within the predetermined period of time from thefirst action item; and upon the computer identifying the one or moredata gaps in the user healthcare profile responsive to determining thatthere is no link between the first and second data records and there isno record of execution of the second action item within thepredetermined period of time: transmitting, by the computer, a web linkto a secure webpage comprising a request to a user computing deviceoperated by the user, wherein the request comprises an instruction topopulate missing information in the one or more data gaps representingexecution of the second action item in the user healthcare profile andto execute the second action item; updating, by the computer, the userhealthcare profile in the second database upon receiving the informationcorresponding to the one or more data gaps representing execution of thesecond action item from the user computing device; and displaying, bythe computer, one or more healthcare reports based on evaluation of thedata in the one or more data fields of the user healthcare profile on agraphical user interface of the user computing device.
 2. Thecomputer-implemented method according to claim 1, wherein the commondata model is selected by the user.
 3. The computer-implemented methodaccording to claim 1, wherein the common data model is selected by thecomputer based on a configuration of the user computing device.
 4. Thecomputer-implemented method according to claim 1, wherein the healthcaredata record of the set of one or more healthcare data records comprisesmachine-readable code containing data fields describing detected useractions and sources of data associated with the user identifier.
 5. Thecomputer-implemented method according to claim 1, wherein the one ormore healthcare data-generating systems comprises fitness wearabledevices, connected devices for weight tracking, connected devices formedical tracking, hospital data-generating systems, and pharmacydata-generating systems.
 6. The computer-implemented method according toclaim 1, further comprising formatting, by the computer, the set of oneor more healthcare data records received from the one or more healthcaredata-generating systems.
 7. The computer-implemented method according toclaim 1, further comprising filtering, by the computer, the plurality ofhealthcare data records associated with the plurality of useridentifiers for each user to generate each of the plurality of userhealthcare profiles comprising data associated with each of theplurality of user identifiers.
 8. The computer-implemented methodaccording to claim 1, further comprising determining, by the computer,whether the data contained in the one or more data fields of the userhealthcare profile comprises a partial amount of information based onidentification of relationships of the data in the one or more datafields of the user healthcare profile with respect to each other.
 9. Thecomputer-implemented method according to claim 1, further comprisinggenerating, by the computer, the one or more healthcare reports based onexecution of one or more analytical algorithm models on the data in theone or more data fields of the user healthcare profile.
 10. Thecomputer-implemented method according to claim 1, further comprising:generating, by the computer, one or more alerts based on application ofone or more rules on data associated with the one or more healthcarereports; and transmitting, by the computer, the one or more alerts onthe user computing device at one or more pre-defined time-intervals. 11.A system comprising: a first database configured to store healthcaredata records; a second database configured to store user healthcareprofiles; and a computer configured to: receive a set of one or morehealthcare data records containing a user identifier from one or morehealthcare data-generating systems configured to generate acorresponding healthcare data record, wherein the one or more healthcaredata-generating systems are configured to generate the correspondinghealthcare data record according to one or more data models associatedwith one or more formats and one or more data types; standardize the setof one or more healthcare data records received from the one or morehealthcare data-generating systems according to a common data modelcomprising mappings specifying transformations from the one or moreformats for all healthcare data records having all of the one or moredata types to a single format and single data type; store thestandardized set of one or more healthcare data records into the firstdatabase configured to store a plurality of healthcare data recordsassociated with a plurality of user identifiers; generate in a seconddatabase, a user healthcare profile of a user associated with the useridentifier, the user healthcare profile comprising one or more datafields containing data from the standardized set of one or morehealthcare data records associated with the user identifier in the firstdatabase, wherein the second database is configured to store a pluralityof user healthcare profiles associated with a plurality of useridentifiers, and wherein each user healthcare profile contains one ormore action items associated with data in each of the one or more datafields; determine that the user healthcare profile contains a firstrecord of a first action item that requires entry of a second recordindicating that a second action item has been performed, wherein thesecond record of the second action item is programmed to require arecord of execution within a predetermined period of time; determinethat the predetermined period of time has elapsed; responsive todetermining that the predetermined period of time has elapsed, determinewhether a record of execution of the second action item is availablefrom the one or more healthcare data-generating systems after thepredetermined period of time elapses, wherein the computer is configuredto trigger a monitoring window for a time period from determination ofthe first action item until the predetermined period of time elapses todetermine the execution of the second action item; identify one or moredata gaps corresponding to missing data in the user healthcare profilebased on a link between the first data record for the first action itemand the second data record for the second action item and when thesecond record does not contain the record of execution of the secondaction item within the predetermined period of time from the firstaction item; and upon the computer identifying the one or more data gapsin the user healthcare profile responsive to determining there is nolink between the first and second data records and there is no record ofexecution of the second action item within the predetermined period oftime: transmit a web link to a secure webpage comprising a request to auser computing device operated by the user, wherein the requestcomprises an instruction to populate missing information in the one ormore data gaps representing execution of the second action item in theuser healthcare profile and to execute the second action item; updatethe user healthcare profile in the second database upon receiving theinformation corresponding to the one or more data gaps representingexecution of the second action item from the user computing device; anddisplay one or more healthcare reports based on evaluation of the datain the one or more data fields of the user healthcare profile on agraphical user interface of the user computing device.
 12. The systemaccording to claim 11, wherein the healthcare data record of the set ofone or more healthcare data records comprises machine-readable codecontaining data fields describing detected user actions and sources ofdata associated with the user identifier.
 13. The system according toclaim 11, wherein the one or more healthcare data generating systemscomprises fitness wearable devices, connected devices for weighttracking, connected devices for medical tracking, hospitaldata-generating systems, and pharmacy data generating systems.
 14. Thesystem according to claim 11, wherein the computer is further configuredto determine whether the data contained in the one or more data fieldsof the user healthcare profile comprises a partial amount of informationbased on identification of relationships of the data in the one or moredata fields of the user healthcare profile with respect to each other.15. The system according to claim 11, wherein the computer is furtherconfigured to: generate one or more alerts based on application of oneor more rules on data associated with the one or more healthcarereports; and transmit the one or more alerts on the user computingdevice at one or more pre-defined time intervals.
 16. Acomputer-implemented method comprising: receiving, by a computer, a setof one or more healthcare data records containing a user identifier fromone or more healthcare data-generating systems configured to generate acorresponding healthcare data record, wherein the one or more healthcaredata-generating systems are configured to generate the correspondinghealthcare data record according to one or more data models associatedwith one or more formats and one or more data types; standardizing, bythe computer, the set of one or more healthcare data records receivedfrom the one or more healthcare data-generating systems according to acommon data model comprising mappings specifying transformations fromthe one or more formats for all healthcare data records having all ofthe one or more data types to a single format and single data type;storing, by the computer, the standardized set of one or more healthcaredata records into a first database configured to store a plurality ofhealthcare data records associated with a plurality of user identifiers;generating, by the computer, in a second database, a user healthcareprofile associated with the user identifier, the user healthcare profilecomprising one or more data fields containing data from the standardizedset of one or more healthcare data records associated with the useridentifier in the first database, wherein the second database isconfigured to store a plurality of user healthcare profiles associatedwith a plurality of user identifiers, and wherein each user healthcareprofile contains one or more action items associated with data in eachof the one or more data fields; identifying, by the computer, one ormore data gaps corresponding to missing data in the user healthcareprofile associated with a user based on a link between data recordscontained in each of the one or more data fields and wherein a linkeddata record does not contain a record of execution of an action item;and upon the computer identifying the one or more data gaps in the userhealthcare profile associated with the user responsive to determiningthere is no link between the data records contained in each of the oneor more data fields: transmitting, by the computer, a web link to asecure webpage comprising a request to populate missing information inthe one or more data gaps representing executing of the action item inthe user healthcare profile to a user computing device operated by theuser; updating, by the computer, the user healthcare profile in thesecond database upon receiving the information corresponding to the oneor more data gaps representing executing of the action item from theuser computing device; and displaying, by the computer, one or morehealthcare reports based on evaluation of the data in the one or moredata fields of the user healthcare profile on a graphical user interfaceof the user computing device.
 17. The computer-implemented methodaccording to claim 16, wherein the common data model is selected by theuser.
 18. The computer-implemented method according to claim 16, whereinthe common data model is selected by the computer based on aconfiguration of the user computing device.
 19. The computer-implementedmethod according to claim 16, wherein the one or more healthcaredata-generating systems comprises fitness wearable devices, connecteddevices for weight tracking, connected devices for medical tracking,hospital data-generating systems, and pharmacy data-generating systems.20. The computer-implemented method according to claim 16, furthercomprising generating, by the computer, the one or more healthcarereports based on execution of one or more analytical algorithm models onthe data in the one or more data fields of the user healthcare profile.